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ABSTRACT 

This  paper  reports  some  aspects  of  the  work 
being  carried  out  on  the  NEUTRABAS  project 
under  the  ESPRIT  II  European  research  program. 
The  aim  of  this  project  is  to  specify  ana  imple¬ 
ment  a  neutral  product  definition  database  for 
large  marine -related  artefacts,  covering  a  large 
part  of  the  complete  product  life-cycle.  The 
results  of  this  research  program  will  facilitate  the 
effective  exchange  of  product-related  data 
between  disparate  computer-based  information 
systems,  and  hence  promote  a  movement  towards 
product  life-cycle  integration.  The  scope  of  the 
product  model  being  developed  as  the  basis  for 
this  integration  is  described  in  terms  of  its  spatial 
and  steel  structural  components,  together  with  the 
implications  for  integration  with  other  models  of 
outfitting  and  engineering  systems.  The  model  is 
shown  to  encompass  the  wide  range  of  product- 
related  data  which  is  associated  with  the  various 
pre-commissioning  stages  of  the  product  life- 
cycle.  A  suitable  database  architecture  designed 
to  support  product  data  exchange  and  full  life- 
cycle  integration  based  on  this  product  model,  is 
described  and  discussed. 

NOMENCLATURE 

AEC  Architecture,  Engineering  and  Con¬ 

struction. 

ASCII  American  Standard  Code  for  Infor¬ 

mation  Interchange. 

CAD  Computer  Aided  Design. 

CADEX  CAD  Geometry  Data  Exchange. 

CAD*1  CAD  Interfaces. 

CALS  Computer  Aided  Acquisition  and 

Logistics  Support. 

CEC  Commission  of  the  European  Com¬ 

munities. 


EDI  Electronic  Data  Interchange. 

ESPRIT  European  Strategic  Program  for 

Research  and  Development  in  Infor¬ 
mation  Technology. 

IGES  Initial  Graphical  Exchange 

Specification. 

ISO  International  Standards  Organisation. 

NIDDESC  Navy  Industry  Digital  Data  Exchange 
Standards  Committee. 

SET  Standard  d’Exchange  et  de  Transfert. 

VDAFS  Verband  der  Deutschen  Automobilin- 

dustrie  Plaechen  Scnittstelle. 

INTRODUCTION 

The  pre-commissioning  stages  in  the  life- 
cycle  of  large,  complex  engineering  artefacts,  of 
which  the  shipbuilding  product  is  an  example,  are 
normally  associated  with  the  generation  and 
management  of  vast  quantities  of  complex,  inter¬ 
related  product  data.  This  data  is  concerned  with 
all  aspects  of  the  product  including  its  geometiy, 
topology,  functionality,  the  associated  production 
processes,  production  planning  and  control, 
materials,  quality  control  and  so  on. 

The  scope  and  complexity  of  the  product- 
related  data  being  created  and  manipulated 
throughout  the  various  pre-commissioning  stages 
of  the  complete  product  life-cycle,  from  require¬ 
ments  analysis,  through  the  various  design  stages 
and  finally  into  production,  requires  that  equally 
comprehensive  and  coherent  data  models  be 
specified  and  implemented  to  enable  the  effective 
management  and  exchange  of  such  diverse  pro¬ 
duct  data  between  the  associated  application 
areas.  The  need  for  such  data  models  is  accen¬ 
tuated  by  the  tendency  to  use  increasingly  com¬ 
plex  heterogeneous  computer-based  information 
systems  at  the  various  pre-commissioning  life- 
cycle  stages.  These  life-cycle  stages  cover  activi¬ 
ties  such  as  marketing,  conceptual  design, 
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detailed  design,  drafting,  materials  ordering,  pro¬ 
duction  planning  and  control,  scheduling,  and 
quality  control.  The  use  of  such  diverse  software 
and  hardware  systems  presents  considerable  obs¬ 
tacles  to  the  effective  management  and  control  of 
the  massive  amounts  of  data  related  to  the  pro¬ 
duct  which  these  systems  both  generate  and  use. 

In  theory,  a  product  data  model  could  and 
should  be  extended  to  cover  the  full  life-cycle  of 
the  product,  from  the  initial  feasibility 
studies/requirements  analysis,  through  the  design 
and  production  stages,  its  operation,  maintenance, 
possible  upgrading  and  finally  its  de¬ 
commissioning  ana  eventual  demolition.  This 
would  ensure  that  all  information  concerning  the 
product  would  be  available  in  a  consistent  and 
system-independent  form  throughout  the  full  pro¬ 
duct  life-cycle  and  even  beyond.  This  period  may 
typically  span  more  than  20  years;  much  longer 
than  several  computer  system  hardware  and 
software  architecture  life-times.  It  is  appreciated, 
however,  that  the  definition  and  implementation 
of  a  complete  product  data  model  covering  all  of 
these  aspects  of  the  life-cycle  of  an  engineering 
product  as  complex  as  a  ship  is  an  onerous  task, 
and  one  which  would  require  the  commitment  of 
a  vast  amount  of  time  and  effort. 

This  paper  reports  on  work  currently  in  pro¬ 
gress  in  Europe  on  the  development  of  a  data 
model  which  will  facilitate  the  integration  of 
those  life-cycle  stages  of  the  shipbuilding  product 
up  to  its  commissioning  and  final  hand-over. 

STANDARDS  FOR  LIFE-CYCLE  INTEGRA¬ 
TION  AND  PRODUCT  DATA  EXCHANGE 

The  many,  non-trivial  problems  associated 
with  the  management  and  exchange  of  product- 
related  data,  have  resulted  in  the  inauguration  of 
a  large  number  of  separate,  but  largely  comple¬ 
mentary  initiatives,  looking  at  the  information 
management  requirements  of  a  wide  range  of 
manufacturing  industries.  These  initiatives  have 
resulted  in  the  specification  of  a  number  of  stan¬ 
dards  in  the  area  of  electronic  data  interchange 
(EDI).  In  some  cases  these  specifications  have 
been  implemented  to  provide  functioning  data 
exchange  systems  for  a  range  of  application 
areas. 

Early  attempts  at  the  development  of  stan¬ 
dards  for  data  exchange  were  largely  concerned 
with  geometry-based  information.  One  such  stan¬ 
dard,  IGES  (Initial  Graphical  Exchange 
Specification)  (1),  allowed  for  the  storage  and 
transfer  of  basic  2-dimensional  geometry  between 
different  computer-aided  design  (CAD)  systems 
in  a  system-independent  form.  Although  support¬ 
ing  the  integration  of  those  activities  which  are 
based  upon  geometrical  data,  IGES  does  not  offer 
any  facilities  for  the  representation  of  information 


regarding  the  topology,  functionality,  material 
characteristics,  production  processes  and  manage¬ 
ment  information  associated  with  a  product,  and 
cannot  therefore  be  used  as  a  vehicle  for  the 
integration  of  information  flow  throughout  the  the 
complete  product  life-cycle. 

Standard  for  the  Exchange  of  Product  Data 

One  of  the  most  significant  attempts  to  cir¬ 
cumvent  the  limitations  of  standards  such  as 
IGES  is  currently  being  carried  out  by  a  commit¬ 
tee  of  the  ISO  (International  Standards  Organisa¬ 
tion)  and  is  commonly  known  as  the  Standard  for 
the  Exchange  of  Product  Data  (STEP)  (2).  The 
aim  of  this  initiative  is  to  provide  a  complete 
representation  of  all  of  the  information  which  can 
be  associated  with  a  product  throughout  its  life¬ 
time  in  a  completely  system-independent  form. 
That  is,  the  basic  goal  is  to  enable  a  product  to 
be  represented  from  the  requirements  definition 
and  conceptual  design  stages  through  to  produc¬ 
tion,  maintenance  and  eventual  demolition.  This 
representation  is  intended  to  include  all  geometric 
and  non-geometric  data  associated  with  that  pro¬ 
duct.  Information  types  to  be  represented  include 
geometry,  topology,  functionality,  cost,  materials, 
strength  and  safety.  STEP  is  formulated  in  a 
structure  consisting  of  an  application  layer  upon 
an  implementation  layer,  with  the  former 
comprising  the  relevant,  domain-specific  data 
models,  and  the  latter  the  actual  implementation 
of  these  models.  The  EXPRESS  data  modelling 
language  (3)  has  been  specifically  developed  for 
use  within  the  application  layer. 

A  large  number  of  individual  data  models 
reside  within  the  STEP  application  layer,  being 
classified  as  either  application  models  or  resource 
models.  Application  models,  such  as  the  ship¬ 
building  and  the  AEC  (Architecture,  Engineering 
and  Constmction)  models,  address  the  require¬ 
ments  of  particular  application  areas.  Resource 
models,  such  as  geometry  or  topology,  are  not 
generally  associated  with  a  specific  application 
area,  but  provide  general  facilities  to  application 
models.  Resource  models  currently  nearing  com¬ 
pletion  within  the  STEP  standard  include 
geometry,  topology,  solids,  features,  material, 
presentation,  AEC  core  and  tolerances.  Similarly, 
application  models  nearing  completion  include 
drafting,  ship  stmctures,  electrical  applications 
and  finite  element  analysis. 

A  STEP  data  model  provides  a  description  or 
specification  of  a  domain  of  interest  and  consists 
of  entities,  attributes  and  relationships.  Entities 
may  be  either  abstract,  such  as  a  powering  calcu¬ 
lation,  or  concrete  concepts  such  as  a  stiffener 
piece-part  .  Entities  may  be  described  by  a 
number  of  attributes  and  referred  to  other  entities 
via  relationships.  The  data  model  contains 
descriptions  and  other  information  including  the 
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constraints  upon  the  value  of  attributes,  global 
constraints  and  textual  descriptions  with  some 
explanation  of  entities.  All  STEP  data  models 
are  ultimately  described  in  the  EXPRESS  data 
modelling  language. 

The  actual  transfer  of  data  between  indivi¬ 
dual  applications  is  achieved  by  means  of  a  phy¬ 
sical  file.  The  STEP  standard  allows  for  the  use 
of  ASCII  characters  only  in  the  physical  file 
description,  and  requires  the  format  to  be  human 
readable.  However,  in  the  majority  of  cases  it  is 
not  necessary  for  the  developer  of  a  model  to  be 
aware  of  the  actual  appearance  of  the  physical 
file. 

Other  Initiatives 

In  addition  to  STEP,  a  number  of  adjunct 
EDI  projects  are  currently  under  development, 
some  of  which  are  providing  a  significant  contri¬ 
bution  to  the  STEP  activities.  Many  of  these  ini¬ 
tiatives  are  collaborative  ventures  supported  by 
the  Commission  of  the  European  Communities 
(CEC)  under  the  ESPRIT  program  of  research 
and  development. 

ESPRIT  (European  Strategic  Progmmme  for 
Research  and  Development  in  Information  Tech¬ 
nology),  founded  in  1983  and  currently  at  phase 
II,  has  included  a  number  of  projects  which  have 
been  significant  to  the  development  of  STEP  such 
as  CAD*I  (CAD  Interfaces)  and  CADEX  (CAD 
Geometry  Data  Exchange).  Many  other  initia¬ 
tives,  also  related  to  STEP,  have  originated  in  the 
United  States  and  Europe  in  support  of  a  wide 
range  of  industrial  interests.  Examples  of  these 
are  the  CALS  (Computer-aided  Acquisition  and 
Logistics  Support),  NIDDESC  (Navy  Industry 
Digital  Data  Exchange  Standards  Committee), 
SET  (Standard  d’Exchange  et  de  Transfert)  and 
VDAFS  (Verband  der  Deutschen  Automobilin- 
dustrie  Flaechen  Scnittstelle)  initiatives.  Further 
details  of  all  of  ‘these  initiatives  can  be  found  in 

(4). 

The  one  common  aim  that  all  of  the 
aforementioned  initiatives  share,  is  that  of  provid¬ 
ing  the  means  for  the  effective  storage  and 
exchange  of  product-related  data  between 
different  applications  in  a  completely  system- 
independent  form. 

One  other  project  which  is  making  a 
significant  contribution  to  the  STEP  initiative  is 
the  ESPRIT  project  NEUTRABAS  (5),  a  project 
which  is  specifically  addressing  the  needs  of  the 
shipbuilding  industry,  and  one  which  is  the  sub¬ 
ject  of  this  particular  paper. 


NEUTRABAS  -  A  NEUTRAL  PRODUCT 
DEFINITION  DATABASE  FOR  LARGE 
MULTI-FUNCTIONAL  SYSTEMS 

The  shipbuilding  industry  in  Europe  has  con¬ 
sistently  been  at  the  forefront  of  technological 
advancement,  with  massive  investment  in  compu¬ 
terized  systems  in  all  parts  of  the  technical  and 
production  areas.  This  application  of  state-of-the- 
art  technology,  as  illustrated  by  the  introduction 
of  computerized  design  and  drafting  systems, 
management  information  systems,  and  advanced 
automated  manufacturing  technologies,  has 
repeatedly  highlighted  the  need  for  some  means 
for  consistently  storing  and  transferring  informa¬ 
tion  in  an  electronic  format,  between  the  various 
activity  areas. 

This  perceived  need  resulted  in  the  develop¬ 
ment  of  a  proposal  for  a  collaborative  project 
under  the  ESPRIT  initiative,  which  would  involve 
a  team  of  industrialists,  academics  and  computer 
scientists  from  four  European  countries.  The  three 
year  NEUTRABAS  project  started  in  April  1989 
and  involves  fifteen  partners  from  the  UK, 
France,  Germany  and  Spain.  The  overall  aims  of 
the  project  can  be  summarised  in  terms  of  four 
main  points,  as  indicated  below  : 

1.  The  standardization  of  the  way  in  which 
information  concerning  marine-related  pro¬ 
ducts  is  represented; 

2.  The  development  of  standard  methods  for  the 
exchange  and  storage  of  product  definition 
data  in  the  marine  industry; 

3.  The  specification  and  development  of  a  suit¬ 
able  database  architecture  which  will  facili¬ 
tate  the  exchange  and  storage  of  such  product 
definition  data;  and 

4.  The  implementation  of  a  prototype  data 
exchange  and  storage  system,  based  on  the 
previously  defined  database  architecture, 
which  will  demonstrate  the  feasibility  of  a 
truly  integrated  product  life-cycle. 

The  Anticipated  Benefits  of  the  NEUTRABAS 
Approach 

The  most  obvious  of  the  anticipated  benefits 
to  arise  from  the  application  of  the  NEUTRA¬ 
BAS  philosophy  is  that  of  life-cycle  stage 
integration.  This  will  be  achieved  through  the 
coherent  and  consistent  storage  and  exchange  of 
product-related  information  between  different 
application  systems.  In  addition  to  this,  a  number 
of  related  benefits  can  be  perceived,  as  indicated 
below. 
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Reduced  project  time-scales  -  The  adoptiopcle  stages,  the  actual  physical  object  being  con- 


of  a  single,  carefully  managed  information 
store  will  enable  overall  project  time-scales 
to  be  reduced.  This  will  be  achieved  through 
the  rigorous  control  of  information  flow  and 
the  subsequent  avoidance  of  mis-matches  in 
information  requirement  and  availability  at 
each  of  the  pre-commissioning  life-cycle 
stages. 

More  effective  information  management  ■  A 

single,  shared  information  storage  facility 
will  enable  the  more  effective  management 
of  all  product-related  data  including  security, 
version  control  and  data  consistency  issues. 


sidered  will  normally  be  unchanged  in  the  global 
sense,  although  the  information  associated  with 
the  product  and  the  techniques  used  to  represent 
it  will  vary  considerably.  For  example,  at  the 
very  earliest  of  the  design  stages,  the  conceptual 
design  stage,  the  product  will  usually  be 
described  in  very  general  terms  using  high-level 
(global)  information,  such  as  intended  speed, 
gross  capacities,  main  dimensions  etc.  As  the 
design  stage  progresses,  additional  information 
concerning  the  product  will  become  available  and 
so  the  early  global  product  information  will  be 
supplemented  by  more  detailed,  lower-level  infor¬ 
mation. 


•  Rapid  information  dissemination  -  The  adop¬ 
tion  of  a  common  shared  information 
resource  will  result  in  more  rapid  information 
dissemination  among  the  various  activities 
involved  at  each  of  the  pre-commissioning 
life-cycle  stages. 

•  Avoidance  of  data  transcription  -  The 

exchange  of  information  between  different 
application  systems  in  an  electronic  format 
will  avoid  the  need  for  manual  or  mechanical 
transcription  of  the  data,  with  the  accom¬ 
panying  risk  of  error  introduction. 

•  Improved  supplier/client  interface  -  In  an 

industry  such  as  shipbuilding,  which  has  a 
high  level  of  bought-in  items  in  its  finished 
product,  considerable  benefits  will  be 
obtained  from  the  provision  of  component 
and  equipment  catalogues  and  specifications 
in  an  electronic  format,  which  can  be  incor¬ 
porated  into  the  product  definition  database. 
This  will  ensure  that  the  most  up-to-date 
information  is  always  available  concerning 
items  of  equipment  obtained  from  outside 
sources. 

THE  DEVELOPMENT  OF  A  SHIPBUILD¬ 
ING  PRODUCT  INFORMATION  MODEL 

The  main  aim  of  the  information  modelling 
process  is  to  develop  a  structured  representation 
of  the  information  associated  with  a  real-world 
physical  object,  which  extends  over  the  required 
life-cycle  stages,  and  also  supports  the  required 
views  or  interpretations  of  the  product  at  each  of 
these  specified  stages. 

According  to  STEP,  the  shipbuilding  product 
is  a  specialisation  of  the  general  AEC  (Architec¬ 
ture,  Engineering  and  Construction)  category  of 
real-world  physical  products.  The  complete  life- 
cycle  of  the  shipbuilding  product  extends  from 
the  requirements  definition/mission  analysis  stage, 
through  the  various  design  stages,  into  production 
and  then  on  to  operation,  maintenance  and  even¬ 
tual  demolition.  At  each  of  these  various  life- 


This  evolution  and  maturing  of  the  informa¬ 
tion  associated  with  the  product,  as  it  progresses 
through  its  various  life-cycle  stages,  demands  that 
any  model  of  this  information  must  be  specified 
and  developed  with  these  life-cycle  stages  in 
mind.  In  the  context  of  the  NEUTRABAS  project 
it  was  not  considered  feasible  to  attempt  to  define 
an  information  model  which  would  support  all  of 
the  product  life-cycle  stages  mentioned  previ¬ 
ously,  as  this  would  require  resources  and  exper¬ 
tise  not  available  within  the  existing  NEUTRA¬ 
BAS  program.  Those  product  stages  which  are 
considered  in  the  NEUTRABAS  product  informa¬ 
tion  models  are  associated  with  the  pre¬ 
commissioning  part  of  the  product’s  life-cycle. 

It  has  already  been  mentioned  that  the  infor¬ 
mation  associated  with  the  physical  product 
matures  as  the  life-cycle  progresses.  In  addition 
to  this  maturing  process,  the  same  information  is 
subject  to  different  points  of  view  or  intetpreta- 
tions  during  a  given  life-cycle  stage.  For  exam¬ 
ple,  if  a  physical  entity  such  as  a  deck  is  con¬ 
sidered  at  the  detailed  design  stage,  the  way  in 
which  this  object  is  described  will  be  dependent 
upon  which  particular  design  activity  is  being 
considered.  The  draftsman  producing  scantling 
drawings  will  be  primarily  concerned  with  load¬ 
ings,  material  properties,  stiffening  arrangements, 
precise  geometry  and  so  on.  Whereas  the  naval 
architect  investigating  flooding,  stability  and  other 
safety-related  characteristics  of  the  product  may 
consider  the  same  entity  as  a  simple  planar  ele¬ 
ment  without  any  of  the  previously  mentioned 
characteristics. 

It  can  ‘therefore  be  seen  that  different  views 
or  interpretations  of  the  same  product  require 
different  aggregations  of  the  information  associ¬ 
ated  with  the  product.  The  problems  associated 
with  developing  a  coherent  model  of  the  informa¬ 
tion  are  further  compounded  by  the  conflicting 
approaches  used  at  the  design  and  production 
stages  of  the  product  life-cycle.  For  example, 
design  is  basically  a  top-down  modelling  activity 
with  global  concepts  being  repeatedly  decom¬ 
posed  into  smaller  information-bearing  units  at 
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subsequent  stages  in  the  design  process,  with  the 
associated  increase  in  the  level  of  detail  of  infor¬ 
mation.  In  contrast,  production-oriented  informa¬ 
tion  modelling  follows  a  bottom-up  strategy,  with 
individual  information  units  being  aggregated  to 
form  larger  units  and  eventually  the  complete 
product  definition. 

In  view  of  the  above  points,  it  can  be  con¬ 
cluded  that  any  information  model  of  a  complex 
physical  product  must  not  only  possess  the  scope 
ana  structure  to  reflect  the  evolution  of  the  asso¬ 
ciated  information  as  the  product  life-cycle 
progresses,  but  must  also  be  able  to  facilitate 
different  views  of  the  product  information  at  each 
of  these  life-cycle  stages.  It  is  with  these  require¬ 
ments  in  mind  that  the  information  models  of 
NEUTRABAS  have  been  developed  to  provide  a 
complete  and  coherent  representation  of  the  ship¬ 
building  product,  throughout  the  relevant  life- 
cycle  stages,  which  accommodates  both  the 
decomposition  and  aggregation  scenarios  associ¬ 
ated  with  the  pre-commissioning  stages  of  the 
complete  product  life-cycle. 

Information  Modelling  Techniques 

The  NEUTRABAS  product  model  is  basi¬ 
cally  comprised  of  a  large  number  of  physical 
and  abstract  objects  which  are  described  by 
means  of  sets  of  attributes.  The  formal 
specification  of  this  model  is  therefore  mainly 
concerned  with  the  complete  and  unambiguous 
description  of  these  objects  (entities)  and  attri¬ 
butes,  together  with  the  means  by  which  they  are 
interrelated  to  form  the  complete  description  of 
the  product.  To  this  end,  the  description  of  the 
entities  and  attributes  and  the  declaration  of  the 
relationships  between  them  is  achieved  in  three 
ways.  First  of  all,  a  natural  language  (English) 
description  of  the  entities  and  attributes  is  given 
which  explains  the  context  in  which  they  are  used 
and  the  restrictions  or  rules  with  affect  their 
usage.  Secondly,  the  entities  and  attributes  are 
represented  in  a  graphical  form.  The  technique 
used  for  this  graphical  representation  is  the 
Nijssen  Information  Analysis  Method  (NIAM) 
(6),  as  adopted  by  the  ISO/STEP  community.  The 
NIAM  diagrams  illustrate  the  relationships 
between  the  various  entities  which  comprise  the 
model,  and  also  specify  the  restrictions  imposed 
on  the  relationships  between  the  individual  enti¬ 
ties  and  attributes.  The  final  method  used  to 
describe  the  components  of  the  product  model  is 
the  EXPRESS  information  modelling  language. 
This  language  provides  a  means  of  generating  a 
formal,  standardized  textual  description  of  the 
components  of  the  model,  together  with  the  rela¬ 
tionships  between  the  various  entities  and  attri¬ 
butes  involved. 

When  combined,  the  three  methods  described 


above  provide  a  complete  and  coherent  descrip¬ 
tion  of  the  product  information  model  of  NEU- 
TRABAS  which  forms  the  basis  for  the  imple¬ 
mentation  and  testing  phases  of  the  project 
described  in  subsequent  sections  of  this  paper. 

THE  NEUTRABAS  PRODUCT  MODEL 

An  analysis  of  the  form  and  stmcture  of  the 
information  associated  with  the  shipbuilding  pro¬ 
duct  identifies  four  basic  views  of  the  information 
which  combine  to  give  a  complete  description  of 
the  product  throughout  its  pre-commissioning 
life-cycle  stages.  These  four  views  are  listed 
below. 

1.  Marketing-oriented  view; 

2.  Management-oriented  view; 

3.  Design-oriented  view;  and 

4.  Production-oriented  view. 

Clearly,  a  shipbuilding  product  model  must 

3ort  each  of  these  high-level  views  of  the 
ict-related  information  in  order  that  integra¬ 
tion  of  the  associated  activities  and  life-cycle 
stages  can  be  supported. 

When  commencing  the  analysis  of  the  infor¬ 
mation  to  be  modelled,  it  is  convenient  to 
categorize  the  information  in  terms  of  whether  it 
is  associated  with  the  hull  of  the  vessel  or  with 
the  machinery  and  outfitting  systems.  This 
enables  the  information  analysis  in  these  two 
complementary  areas  to  be  carried  out  in  parallel, 
with  agreed  integration  points  providing  the 
means  for  the  concatenation  of  the  two  sub¬ 
models.  In  the  context  of  NEUTRABAS,  this 
approach  was  adopted  in  the  product  modelling 
process  with  the  result  that  two  information 
models  were  developed  covering  the  information 
concerned  with  the  hull  of  the  vessel,  and  that 
associated  with  the  machinery  and  outfitting  sys¬ 
tems.  This  paper  is  primarily  concerned  with  the 
model  which  describes  the  information  associated 
with  the  hull  of  the  vessel  and  which  covers  both 
the  steel  stmcture  and  the  spatial  arrangement  of 
the  product. 

The  High-Level  Product  Model 

In  very  general  terms,  information  relating  to 
the  shipbuilding  product  can  be  placed  into  one 
of  three  main  categories  : 

1.  Global  information; 

2.  Information  relating  to  the  hull;  and 

3.  Information  relating  to  machinery  and 
outfitting  systems. 
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Fig.l  NIAM  diagram  of  the  NEUTRABAS  high-level  model. 


Therefore,  at  the  highest  level,  a  shipbuilding 
product  information  model  can  be  considered  as 
comprising  separate  sub-models  of  global,  hull 
and  machinery /outfit  information,  as  shown  in 
NIAM  form  in  Fig.l. 

The  Hull  Model 

As  mentioned  previously,  a  product  model 
contains  descriptions  of  a  number  of  physical  or 
abstract  objects  and  their  associated  attributes 
together  with  details  of  their  relationships  with 
other  objects.  In  the  context  of  the  NEUTRABAS 
hull  model,  the  entities  can  be  divided  into  two 
main  categories;  those  associated  with  the 
representation  of  the  structure  of  the  the  vessel 
and  those  associated  with  its  spatial  organization. 
Although  these  two  groupings  can  be  considered 
as  distinct  concepts,  in  reality  they  are  mutually 
dependent,  a  fact  which  is  reflected  in  the  NEU¬ 
TRABAS  hull  model. 

The  spatial  organization  model.  Reference 
to  the  spatial  characteristics  of  the  shipbuilding 
product  will  be  found  at  all  of  the  pre¬ 
commissioning  life-cycle  stages.  In  fact,  the  ear¬ 
liest  of  the  design-related  stages,  the  conceptual 
design  stage,  is  almost  entirely  concerned  with 
the  spatial  aspects  of  the  product,  i.e.  the 
definition  of  an  acceptable  general  arrangement 
for  a  design  proposal.  This  will  involve  the  mani¬ 
pulation  of  simple  planar  elements  which  com¬ 


bine  to  form  the  boundaries  of  enclosed  spaces  or 
compartments,  and  the  gross  sub-division  of  the 
product  into  various  functional  zones,  i.e.  cargo 
spaces,  machinery  spaces,  accommodation  etc.  It 
should  be  appreciated  that  the  decisions  made  at 
this  stage  in  the  design  process  concerning  the 
spatial  organization  of  the  product  can  have  a 
significant  effect  on  the  overall  quality  of  the 
finished  product  in  terms  of  both  its  production 
and  operational  characteristics.  Even  at  this  early 
stage,  the  spatial  organization  of  the  product  will 
be  related  to  production,  operational  and  other 
considerations.  For  example,  the  disposition  of 
the  main  transverse  sub-division  members  will 
normally  be  based  on  standard  lengths  of  cargo 
holds,  derived  either  from  consideration  of  the 
size  of  cargo  units  to  be  carried  (containers,  pal¬ 
lets  etc.),  or  from  the  maximum  plate  size  which 
can  be  accommodated  by  the  production  facilities 
being  considered  (reduced  work  content  etc.). 

At  each  of  the  stages  in  the  complete  product 
design  cycle,  information  relating  to  the  spatial 
organization  of  the  product  will  be  required  as 
this  forms  the  basis  for  many  of  the  associated 
design  activities.  In  fact,  many  design  activities 
rely  solely  on  the  availability  of  spatial-oriented 
information  relating  to  the  product.  The  nature  of 
this  information  will  change  as  the  design  process 
progresses  from  the  concept  stage  to  the  detailed 
production-oriented  design  stage,  reflecting  the 
evolution  and  maturing  of  the  product  description. 
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Fig.  2  NIAM  diagram  of  the  spatial  organisation  model. 


The  need  for  the  spatial  organization  model  to 
reflect  this  evolution  of  the  product  definition 
through  the  various  life-cycle  stages  and  to  sup¬ 
port  different  views  of  the  information,  is  there¬ 
fore  quite  obvious. 

In  the  context  of  NEUTRABAS,  the  spatial 
organization  model  is  comprised  of  a  number  of 
basic  elements  which  combine  to  support 
geometrical,  topological  and  functional  descrip¬ 
tions  of  the  space-related  characteristics  of  the 
complete  product.  These  components  of  the 
NEUTRABAS  spatial  organization  model  are 
shown  in  NIAM  form  in  Fig. 2.  The  aim  of  this 
spatial  model  is  to  support  the  many  applications 
which  require  space-oriented  product  information 
pertaining  to  the  various  pre-commissioning  life- 
cycle  stages. 


It  is  to  be  appreciated  that  the  spatial  organi¬ 
zation  model,  like  all  of  the  other  NEUTRABAS 
information  models,  draws  upon  the  information 
contained  in  the  general  resource  models  of  STEP 
such  as  those  concerned  with  geometry  and  topol¬ 
ogy.  The  integration  of  these  general  models  with 
the  spatial  organization  model  removes  the  need 
for  the  explicit  declaration  of  the  associated  enti¬ 
ties  within  the  model  being  described  here. 

As  can  be  seen  in  Fig.2,  the  NEUTRABAS 
spatial  organization  model  is  basically  a  collec¬ 
tion  of  systems  which  combine  to  describe  the 
geometrical  and  topological  characteristics  of  the 
internal  organization  of  a  vessel.  These  include 
the  definition  of  the  surfaces  which  combine  to 
form  the  internal  arrangement  of  the  product,  the 
internal  enclosed  spaces  or  compartments,  and  the 
reference  systems  which  facilitate  the  orientation 
and  location  of  components  of  the  product  in 
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Fig.  3  NIAM  diagram  of  the  global  reference  system  concept. 


three-dimensional  space. 

In  order  to  illustrate  the  breadth  and  depth  of 
the  neutrabAs  spatial  organization  model  the 
following  paragraphs  describe  a  number  of  the 
components  of  the  model  in  terms  of  the  entities 
involved  together  with  their  associated  attributes 
and  their  relationships  with  other  entities. 


The  global  reference  system.  The  global 

reference  system  is  perhaps  one  of  the  most 
important  components  of  the  spatial  organization 
model  as  it  provides  the  means  for  the  orientation 
and  location  of  all  of  the  abstract  and  physical 
objects  associated  with  the  definition  of  the  pro¬ 
duct.  The  NEUTRABAS  global  reference  system 
concept  is  shown  in  NIAM  form  in  Fig. 3,  and 
can  be  seen  to  comprise  a  number  of  elements  as 
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listed  below  : 

•  one  or  more  transverse  reference  planes; 

•  one  or  more  longitudmal  reference  planes; 

•  one  or  more  horizontal  reference  planes;  and 

•  a  co-ordinate  system. 

Transverse,  longitudinal  and  horizontal  refer¬ 
ence  planes  can  be  associated  with  the  location 
and  orientation  of  physical  entities  such  as 
frames,  bulkheads,  decks  and  so  on,  or  abstract 
entities  such  as  the  boundaries  of  functional 
zones.  The  co-ordinate  system  component  is  itself 
comprised  of  two  separate  parts;  a  reference  co¬ 
ordinate  system  and  an  axis  set.  This  reference 
co-ordinate  system  has  associated  with  it  a  global 
origin  and  its  own  axis  set.  The  global  reference 
system  concept  is  shown  diagrammatically  in 
Fig-4. 


System 


Fig.4  Diagrammatic  representation  of  the 
global  reference  system  concept. 

Internal  compartmentation.  The  spatial 
organization  model,  as  its  name  suggests,  is  also 
concerned  with  the  representaion  of  the  internal 
enclosed  spaces  on  a  vessel.  This  representation 
requires  the  introduction  of  the  concepts  of 
spaces,  compartments  and  moulded  surfaces. 
Moulded  surfaces  are  non-stmctural  boundaries 
within  the  overall  envelope  of  the  product,  which 
may  provide  the  topological  and  geometrical 
references  for  associated  structural  boundaries. 
Monlded  surfaces  may  also  form  part  of  the 
boundaries  of  physical  or  hypothetical  enclosed 


spaces  within  the  internal  arrangement  of  the  pro¬ 
duct.  A  variety  of  means  can  be  used  to  define 
these  surfaces  including  a  variety  of  mathematical 
techniques  such  as  the  Bezier  and  B-spline  for¬ 
mulations.  The  NIAM  representation  of  the 
moulded  surface  concept  is  shown  in  Fig. 5, 
which  also  indicates  the  various  attributes  which 
are  associated  with  a  particular  occurrence  of  a 
moulded  surface. 

As  mentioned  above,  moulded  surfaces  can 
define  the  boundaries  of  the  internal  enclosed 
spaces  on  a  vessel.  These  spaces  can  either  be 
hypothetical  sub-divisions  of  the  vessel,  as  in  the 
case  of  a  functional  sub-division,  or  physical 
compartments  used  for  the  carriage  of  revenue¬ 
earning  material  or  material  required  for  the 
effective  operation  of  the  vessel  such  as  fuel  oil 
and  water.  The  compartment  concept  is  shown  in 
NIAM  form  in  Fig. 6,  and  diagrammatically  in 
Fig.7.  Fig.6  shows  the  various  types  of  compart¬ 
ments  which  can  be  found  on  a  vessel,  with  the 
attributes  which  can  be  possessed  by  any  com¬ 
partment  being  shown  in  NIAM  form  in  Fig. 8, 
although  it  should  be  appreciated  that  particular 
types  of  compartments  will  have  additional  attri¬ 
butes  which  are  peculiar  to  them. 

As  mentioned  previously,  the  spatial  organi¬ 
zation  model  is  closely  related  to  that  of  the 
structural  organization  as  it  provides  references 
for  the  location  and  orientation  of  the  associated 
structural  components.  Additional  details  of  the 
NEUTUBAS  spatial  organization  model  can  be 
found  in  (7). 

The  structural  organization  model.  The 

NEWTRABAS  structural  organization  model  is 
largely  based  upon  a  top-down  analysis  of  the 
information  associated  with  the  representation  of 
the  structural  components  of  the  shipbuilding  pro¬ 
duct.  The  structure  of  the  model  is  based  upon 
the  repeated  decomposition  of  the  information¬ 
bearing  units  into  their  constituent  parts  until  the 
required  level  of  granularity  or  detail  is  achieved. 
This  approach  can  be  compared  to  the  overall 
design  process  where  high-level  representations 
of  the  product  are  repeatedly  refined  until  the 
complete  product  is  defined  in  terms  of  individual 
piece-parts  and  components.  This  top-down  view 
of  the  product  may  be  representative  of  the 
design  process,  but  is  in  direct  opposition  to  the 
normal  production-related  view  which  tends  to 
follows  a  bottom-up  approach  where  individual 
piece-parts  and  components  are  aggregated  to 
form  sub-assemblies,  assemblies,  units,  blocks 
and  eventually  the  complete  product.  Therefore, 
in  order  to  support  the  information  requirements 
of  the  production-related  life-cycle  stages,  the 
NEUTRABAS  structural  model  has  to  support 
both  the  decomposition  and  aggregation  views  of 
the  product. 


VBl-9 


Fig.  5  NIAM  diagram  of  the  moulded  surface  concept. 


The  generalised  NEUTRABAS  structural 
organization  model  is  shown  in  NIAM  form  in 
Fig.9.  The  diagram  shows  that  the  structural  sys¬ 
tem  of  the  shipbuilding  product  is  considered  as 
comprising  a  number  of  non-overlapping  struc¬ 
tural  elements,  where  each  of  these  structural  ele¬ 
ments  corresponds  to  a  functional  zone  of  the 
vessel,  i.e.  a  double-bottom  region  or  a  main 
engine  compartment.  These  individual  structural 
elements  are  composed  of  a  number  of  pre¬ 
fabricated  blocks  which  are  themselves  made  up 
of  pre-fabricated  sub-blocks  or  units  which  con¬ 
tain  assemblies  of  plate  and  stiffener  piece-parts. 
This  decomposition  is  illustrated  in  NIAM  form 
in  Fig.  10,  and  shown  diagrammatically  in  Fig.ll. 
It  can  be  appreciated  that  this  type  of  representa¬ 
tion  of  the  information  associated  with  the  struc¬ 
ture  of  the  vessel  is  predominantly  a  production- 
related  view  of  that  product  as  these  pre¬ 


fabricated  blocks  and  sub-blocks  are  the  primary 
outputs  of  the  various  production  processes. 
However,  the  general  model  also  incorporates  a 
different  view  of  the  structural  representation  of 
the  product,  one  which  is  associated  with  the 
various  design  stages.  This  design-related  view 
considers  the  structural  elements  to  be  comprised 
of  a  collection  of  primary  sub-structures  which 
correspond  to  the  major  plate  panels  together 
with  their  associated  stiffening  members.  These 
plate  panels  represent  the  major  structural  entities 
of  the  vessel  such  as  complete  decks,  bulkheads 
and  the  outer  shell.  This  type  of  representation  is 
comparable  with  the  view  often  used  at  the 
design  stages  where  the  structural  arrangement  of 
complete  decks  or  bulkheads  are  considered 
without  regard  for  the  eventual  sub-division  of 
the  entities  which  is  required  for  the  production 
processes,  and  is  shown  in  NIAM  form  in  Fig.  12. 
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Fig.8  NIAM  diagram  of  the  compartment  concept  and  attributes. 
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Fig.9  NIAM  diagram  of  the  general  structural  model. 
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Fig.  10  NIAM  diagram  of  the  sub-block  concept. 


The  NEUTRABAS  structural  model  has  been 
developed  so  as  to  support  both  of  the  major 
views  of  the  product  which  are  associated  with 
the  pre-commissioning  life-cycle  stages,  i.e. 
design  and  production.  The  complete  model 
defines  all  of  the  information  which  can  be  asso¬ 
ciated  with  the  structural  system  of  the  product 
including  information  such  as  the  type  and  grade 
of  materials,  the  weights  and  centres  of  parts  and 
assemblies,  details  of  welding  procedures,  and 
production  management  information,  as  well  as 
information  concerning  the  precise  geometry  and 
scantlings  of  individual  parts  and  assemblies. 
Further  details  of  the  structural  model  can  be 
found  in  (8). 


Model  Integration 

The  previous  sections  have  briefly  described 
a  few  of  the  components  of  the  NEUTRABAS 
hull  information  model.  The  complete  hull  model 
provides  a  comprehensive  definition  of  the  type 
and  structure  of  the  information  which  can  be 
associated  with  the  hull  part  of  the  shipbuilding 
product.  It  should  however  be  appreciated  that 
the  hull  model  is  only  one  part  of  the  complete 
description  of  the  complete  product,  and  that  the 
various  systems  which  are  installed  in  the  hull 
such  as  EIVAC,  electrical,  pumping  and  the  vari¬ 
ous  machinery  systems,  are  of  equal  importance 
in  the  specification  of  the  complete  shipbuilding 
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Fig.  11  Diagrammatic  representation  of  the  sub-block  concept. 


product  model.  The  machinery  and  outfitting  sys¬ 
tems  model  is  fully  described  in  (9).  In  addition, 
the  various  resource  models  defined  by  STEP 
have  to  be  integrated  so  as  to  provide  access  to 
descriptions  of  entities  dealing  with  topics  such 
as  geometry  and  topology. 

The  integration  of  these  separate  sub-models 
into  a  single  product  model  is  currently  receiving 
considerable  attention  within  the  NEUTRABAS 
project,  as  it  is  this  fully  integrated  model  which 
will  form  the  basis  for  the  implementation  of  the 
product  definition  into  a  working  data  exchange 
and  storage  facility. 

THE  NEUTRABAS  SYSTEM  ARCHITEC¬ 
TURE 

As  previously  stated,  the  NEUTRABAS  pro¬ 
ject  is  different  from  many  of  the  related  activi¬ 
ties  in  that  it  will  be  taken  beyond  the  formal 
specification  stage  and  will  achieve  partial  imple¬ 
mentation.  In  order  to  reach  this  implementation 
phase,  a  significant  part  of  the  effort  associated 
with  NEITTRABAS  has  been  devoted  to  the 
specification  and  implementation  of  a  suitable 
system  architecture,  as  described  in  (10),  which 
will  facilitate  the  effective  management  and 
transfer  of  product  data  in  the  shipbuilding  indus¬ 
try  context.  A  brief  description  of  the  main 


features  of  the  NEUTRABAS  system  architecture 
is  given  in  the  following  sections. 

Requirements  of  the  Proposed  Architecture 

When  considering  a  suitable  system  architec¬ 
ture  for  the  NEUTRABAS  project,  a  number  of 
significant  requirements  were  identified,  as  indi¬ 
cated  below. 

•  The  system  would  have  to  be  hardware  and 
software  independent  as  the  typical  shipbuild¬ 
ing  product  life-cycle  is  in  excess  of  20 
years;  a  period  far  exceeding  the  current  and 
anticipated  life-spans  of  both  computer 
hardware  and  software. 

•  The  system  would  have  to  be  capable  of  stor¬ 
ing  both  information  models  and  data  models 
as  the  storage  of  data  only  in  a  neutral  for¬ 
mat  is  of  no  real  value.  The  semantics  of  the 
relationships  between  the  data  items  will  also 
need  to  be  defined  and  stored. 

•  The  system  would  need  to  be  independent  of 
the  application  area.  As  NEUTRABAS  is 
intended  to  cover  all  of  the  pre¬ 
commissioning  stages  of  the  product  life- 
cycle,  it  has  therefore  to  be  capable  of  stor¬ 
ing  information  together  with  the  view  or 
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Fig. 12  NIAM  diagram  of  the  structural  element  concept. 

interpretation  of  that  information  for  any  The  Proposed  Architecture 
application  system  at  any  stage  in  the 

product's  pre-commissioning  life-cycle.  The  proposed  main  components  of  the  com¬ 

plete  NEUTRABAS  implementation  environment 
i  The  system  would  have  to  be  dynamic  as  are  shown  diagrammatically  in  Fig.  13.  The  NEU- 

NEUTRABAS  will  be  able  to  share  informa-  TRABAS  system  architecture  is  intended  to  pro- 

tion  between  large  number  of  application  sys-  yihe  all  of  the  means  necessary  for  the  creation 

terns  and  users,  and  must  therefore  have  the  of  schemata,  from  previously  defined  product 

capability  to  interrogate  and  update  the  data-  information  models,  for  a  variety  of  database 

base  asynchronously.  Equally,  it  must  allow  management  system  architectures;  the  facilities 

for  the  evolution  of  the  information  model  needed  for  the  effective  management  of  product 

itself,  data  contained  in  these  databases;  and  the  various 

interfaces  which  will  permit  various  application 
systems  to  communicate  with  this  neutral 
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Fig.  13  The  NEUTRABAS  system  architecture. 


application-independent  store  of  product  informa¬ 
tion.  The  main  features  and  functions  of  each  of 
these  components  are  outlined  in  the  following 
sections. 

The  EXPRESS  model.  This  component  of 
the  system  is  the  domain-specific  information 
model  which  completely  defines  the  shipbuilding 
product  in  terms  of  the  information  used  to 
describe  and  represent  it  at  each  of  its  life-cycle 
stages.  The  model  is  independent  of  any  applica¬ 
tion,  and  is  written  in  the  STEP  information 
modelliig  language  EXPRESS.  The  model  itself 
will  not  be  static,  and  will  continue  to  evolve 


over  time. 

The  data  dictionary.  The  data  dictionary 
contains  the  dynamic  form  of  the  EXPRESS 
model  described  above.  It  comprises  a  formal 
definition  of  the  structure  of  the  data  contained  in 
the  database,  together  with  information  concern¬ 
ing  how  the  individual  items  of  data  are  related 
to  each  other.  The  data  dictionary  allows 
requests  to  the  database  to  be  validated  or  it  can 
alternatively  be  used  to  return  the  complete 
definition  of  the  structure  of  an  entity.  This  par¬ 
ticular  component  can  also  be  used  to  control 
security  issues  such  as  update  rights,  view  rights, 
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versionning  etc.  for  all  of  the  requesting  applica¬ 
tion  systems. 

EXPRESS  import.  The  EXPRESS  import 
facility  is  a  software  tool  which  maps  from  the 
EXPRESS-based  product  information  model  to 
the  data  dictionary  defined  in  the  above  section. 

The  data  management  component  (DMC). 
The  data  management  component  is  effectively 
the  core  of  the  NEUTRABAS  system.  Its  main 
tasks  are  to  facilitate  communication  between  the 
other  components  of  the  system  and  to  convert 
requests  in  any  one  system-specific  format  to  that 
of  any  other  system.  In  order  to  carry  out  these 
tasks,  the  data  management  component  consists 
of  four  main  sub-components,  as  described 
below. 

1.  Data  Management  Interface  -  This  is  the 
external  view  of  the  NEUTRABAS  system 
which  contains  a  procedural  interface  to 
allow  individual  application  systems  to  com¬ 
municate  with  the  neutral  database. 

2.  Data  Management  Kernel  -  This  component 
allows  the  creation,  modification  and  query¬ 
ing  of  items  of  information  by  the  connected 
application  systems.  To  facilitate  this,  the 
data  management  kernel  uses  the  data  struc¬ 
ture  and  relationship  definitions  contained  in 
the  data  dictionary  component  described  pre¬ 
viously.  Those  requests  received  from  the 
data  management  interface  are  reduced  to 
more  simple  instructions  by  the  data  mange- 
ment  kernel  before  being  passed  on  to  the 
virtual  database  interface. 

3.  Data  Dictionary  Interface  -  This  allows  the 

other  elements  of  the  data  management  com¬ 
ponent  to  query  the  data  dictionary  for 
detailed  information  on  entities  and  their 
associated  attribute  structures. 

4.  Virtual  Database  Interface  -  This  is  a  pro¬ 
cedural  interface  which  allows  different  data¬ 
base  management  systems  (DBMS)  to  be 
connected  to  the  NEUTRABAS  system,  in 
order  to  provide  storage  and  data  manage¬ 
ment  facilities. 

The  application  interface.  The  application 
interface  is  the  specific  interface  which  resides 
between  a  given  application  system  and  the  neu¬ 
tral  database.  The  interface  itself  may  be  one  of 
two  types.  It  may  either  be  interactive  or  can  sim¬ 
ply  consist  of  a  pair  of  pre  and  post-processors, 
depending  upon  the  nature  of  the  specific  applica¬ 
tion  system  being  considered.  The  interface  may 
be  written  in  any  high-level  programming 
language  providing  that  a  suitable  language  bind¬ 
ing  is  available. 


The  database  interface.  The  database  inter¬ 
face  is  the  specific  interface  which  permits  com¬ 
munication  between  a  particular  database  manage¬ 
ment  system  and  the  neutral  database,  and  is  a 
mapping  of  the  virtual  database  interface  onto  an 
actual  database  system.  Unlike  the  application 
interface,  the  database  interface  can  utilize 
accepted  database  standards  such  as  SQL  (struc¬ 
tured  query  language)  for  complete  classes  of 
database  management  systems.  The  database 
interface  is  a  vital  component  of  the  NEUTRA¬ 
BAS  system  architecture,  as  it  is  intended  that  a 
NEUTRABAS  product  model  will  be  capable  of 
being  stored  in  any  commercial  database  system. 

The  database  generator.  The  database  gen¬ 
erator  is  a  tool  which  will  map  the  definition  of 
the  product  information  model  contained  in  the 
data  dictionary  to  a  specific  database  implementa¬ 
tion.  While  performing  this  task  it  updates  the 
data  dictionary  so  as  to  provide  information 
regarding  the  location  of  entities  and  their  associ¬ 
ated  attributes  in  the  actual  database  system.  It  is 
quite  obvious  that  a  separate  database  generator  is 
required  for  each  specific  database  management 
system  being  considered  for  connection  to  the 
neutral  database.  At  present,  consideration  has 
been  limited  to  the  relational  and  object  oriented 
database  paradigms,  together  with  the  STEP 
working  form  file  although  it  is  hoped  that  other 
database  types  will  be  considered  in  the  future. 

THE  PROTOTYPE  IMPLEMENTATION 
SYSTEM 

The  previous  sections  of  this  paper  have 
described  various  aspects  of  the  information 
model  of  the  shipbuilding  product  which  has  been 
developed  to  form  the  basis  of  the  NEUTRABAS 
data  exchange  and  storage  system,  together  with  a 
suitable  architecture  for  the  actual  implementation 
of  the  system  in  the  shipbuilding  environment.  In 
order  to  validate  both  the  information  model  and 
the  proposed  system  architecture  it  is  necessary  to 
perform  some  form  of  implementation  to  demon¬ 
strate  the  controlled  exchange  of  product-related 
information  between  two  or  more  disparate  com¬ 
puter  systems,  and  also  to  demonstrate  the  con¬ 
sistent  time-independent  storage  capabilities  of 
the  NEUTRABAS  system.  Unfortunately,  due  to 
limitations  on  time  and  other  resources,  it  is  not 
considered  feasible  to  implement  a  full  version  of 
the  NEUTRABAS  product  model  or  attempt  to 
produce  all  of  the  software  tools  specified  in  the 
system  architecture.  However,  a  significant  sub¬ 
set  of  the  complete  product  model  specification 
will  be  implemented,  as  will  the  key  software 
tools,  in  order  to  provide  a  realistic  test  environ¬ 
ment  for  the  NEUTRABAS  approach. 

Although  the  aim  of  NEUTRABAS  is  to 
facilitate  the  complete  integration  of  all  informa¬ 
tion  systems  in  use  at  all  of  the  product  life-cycle 
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stages,  for  the  purpose  of  validating  the  basic 
philosophy  it  has  been  decided  to  connect  two, 
possibly  three,  different  application  systems  to  the 
NEUTRABAS  system.  The  two  definite  candi¬ 
dates  for  this  prototype  testing  system  are 
CADIS,  a  steel  structure  design  system,  and 
CREST  A  which  is  a  production  planning  sytstem. 
The  third  possible  candidate  is  a  preliminary  ship 
design  system  named  SPAN,  which  will  be 
included  in  the  validation  exercise  if  resources 
permit.  Even  with  only  two  application  systems  it 
will  be  possible  to  demonstrate  how  systems  in 
different  application  areas,  each  having  a  different 
view  of  the  product,  can  be  made  to  communicate 
in  an  effective  manner  and  share  common  infor¬ 
mation  in  a  coherent  and  consistent  way.  Thus 
demonstrating  that  the  true  goal  of  a  fully 
integrated  product  life-cycle  is  indeed  one  which 
could  be  achieved. 

As  previously  stated,  the  testing  system  will 
involve  the  implementation  of  only  a  sub-set  of 
complete  shipbuilding  product  model.  This  sub¬ 
set  will  in  fact  comprise  part  of  the  steel  structure 
of  the  cargo  region  of  a  container  carrying  mer¬ 
chant  vessel,  consisting  of  a  number  of  pre¬ 
fabricated  production  units.  It  is  considered  that 
the  selected  sub- set  contains  sufficient  entities 
from  the  complete  model  to  provide  quite  a 
rigorous  test  of  the  NEUTRABAS  philosophy  in 
the  area  of  preliminary  and  production-oriented 
design,  and  in  the  complementary  area  of  produc¬ 
tion  planning  and  control. 

The  ORACLE  relational  database  manage¬ 
ment  system  has  been  selected  to  provide  the 
means  for  the  storage  and  retrieval  of  the  physi¬ 
cal  data  created  and  used  by  the  application  sys¬ 
tems,  although  in  theory  any  relational  or  object- 
oriented  database  system  could  have  been  chosen. 
At  the  time  of  writing  this  paper,  work  is 
currently  being  carried  out  on  the  implementation 
of  the  prototype  system  with  its  completion  being 
scheduled  for  March  1992. 

CONCLUSIONS 

This  paper  has  described  some  of  the  work 
being  earned  out  on  the  NEUTRABAS  project  in 
the  area  of  neutral  data  exchange  and  storage  in 
the  shipbuilding  industry.  The  progress  outlined 
in  this  paper  has  demonstrated  the  feasibility  of 
achieving  a  truly  integrated  shipbuilding  environ¬ 
ment  through  the  coherent  and  consistent  storage 
and  exchange  of  information  relating  to  the  pro¬ 
duct  at  all  of  the  pre-commissioning  stages  in  its 
life-cycle.  An  information  model  of  the  shipbuild¬ 
ing  product  which  will  accommodate  the  various 
views  and  information  requirements  of  the  many 
computer-based  systems  used  in  the  European 
shipbuilding  industry  has  been  described.  A  neu¬ 
tral  system  architecture  which  will  facilitate  the 
implementation  of  this  information  model  and 


subsequently  provide  database  management  func¬ 
tions  for  the  manipulation  of  the  various 
product-related  data  created  and  used  by  the  vari¬ 
ous  application  systems  in  use  in  the  shipbuilding 
environment,  has  also  been  described.  In  addition, 
the  proposed  prototype  implementation  system 
which  will  demonstrate  the  application  of  the 
NEUITRABAS  concepts  in  a  working  environ¬ 
ment  has  been  outlined. 

NEUTRABAS  is  only  one  of  many  initia¬ 
tives  being  carried  out  in  the  area  of  product  data 
exchange  throughout  the  world.  It  is,  however, 
considered  to  be  one  of  the  leaders  in  this  field 
and  as  such  is  actively  contributing  to  the  emerg¬ 
ing  international  standard  for  the  exchange  of 
product  data,  STEP. 
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